Solid State Drives (SSDs), using flash memory, have become a viable alternative to Hard Disc Drives in many applications. Such applications include storage for notebook, tablets, servers and network attached storage appliances. In notebook and tablet applications, storage capacity is not too high, and power and or weight and form factor are key metric. In server applications power and performance (sustained read/write, random read/write) are key metrics. In network attached storage appliances capacity, power and performance are key metrics, and capacity is achieved by employing a plurality of SSDs in the appliance. The SSD may be directly attached to the system via a bus such as SATA, SAS or PCIe.
Flash memory is a block based non-volatile memory with each block is organized into and made of various pages. After a block is programmed it must be erased prior to programming it again, most flash memory require sequential programming of pages within a block. Another limitation of flash memory is that blocks can be erased for a limited number of times, thus frequent erase operations reduce the life time of the flash memory. A Flash memory does not allow in-place updates. That is it cannot overwrite new data into existing data. The new data are written to erased areas (out-of-place updates), and the old data are invalidated for reclamation in the future. This out-of-place update causes the coexistence of invalid (i.e. outdated) and valid data in the same block. Garbage Collection is the process to reclaim the space occupied by the invalid data, by moving valid data to a new block and erasing the old block. Garbage collection results in significant performance overhead as well as unpredictable operational latency. As mentioned flash memory blocks can be erased for a limited number of times. Wear leveling is the process to improve flash memory life time by evenly distributing erases over the entire flash memory (within a band).
The management of blocks within flash based memory system including SSDs is referred to as flash block management and includes: Logical to Physical Mapping, Defect management for managing defective blocks (blocks that were identified to be defective at manufacturing and grown defective blocks thereafter), wear leveling to keep program/erase cycle of blocks within a band, keeping track of free available blocks, garbage collection for collecting valid pages from a plurality of blocks (with a mix of valid and invalid page) into one block and in the process creating free blocks. The flash block management requires maintaining various tables referred to as flash block management tables (or “flash tables”). These tables are generally proportional to the capacity of SSD. Generally the flash block management tables can be constructed from metadata maintained on flash pages. Metadata is non-user information written on a page. Such reconstruction is time consuming and generally performed very infrequently upon recovery during power up from a failure (such as power fail).). In one prior art technique, technique the flash block management tables are maintained in a volatile memory, and as mentioned the flash block management tables is constructed from metadata maintained on flash pages during power up. In another prior art technique, the flash block management tables are maintained in a battery-backed volatile memory, utilized to maintain the contents of volatile memory for an extended period of time until power is back and tables can be saved in flash memory. In yet another prior art technique the flash block management tables are maintained in a volatile RAM, the flash block management tables are periodically and/or based on some events (such as a Sleep Command) saved (copied) back to flash, and to avoid the time consuming reconstruction upon power up from a power failure additionally a power back-up means provides enough power to save the flash block management tables in the flash in the event of a power failure. Such power back-up may comprise of a battery, a rechargeable battery, or a dynamically charged super capacitor.
The flash block management is generally performed in the SSD and the tables reside in the SSD. Alternatively the flash block management may be performed in the system by a software or hardware, commands additionally include commands for flash management commands and the commands use physical address rather than logical address. An SSD wherein the command use physical address is referred to as Physically Addressed SSD. The flash block management tables are maintained on the (volatile) system memory.
In a system employing physically addressed SSD which maintains the flash block management tables on the system memory that has no power back means for the system and no power back means for the system memory, the flash block management tables that resides in the system memory will be lost and if copies are maintained in the flash onboard the SSD, the copies may not be updated and/or may be corrupted if power failure occurs during the time a table is being saved (or updated) in the flash memory. Hence, during a subsequent power up, during initialization the tables have to be inspected for corruption due to power fail and if necessary recovered. The recovery requires reconstruction of the tables to be completed by reading metadata from flash pages and results in further increase in delay for system to complete initialization. The process of completely reconstruction of all tables is time consuming, as it requires metadata on all pages of SSD to be read and processed to reconstruct the tables. Metadata is non-user information written on a page. This flash block management table recovery during power up will further delay the system initialization, the time to initialize the system is a key metric in many applications.
Additionally a system employing physically addressed SSD it would be advantages to issue writes in units of pages of flash and aligned to a page boundary and avoid partial page or misaligned write to the SSD, as it avoids reading from SSD and merging modified portion of the page with unmodified portion of the page. As information is kept in system memory the partial page is subject to loss in the event of power outage.
Yet another similar problem of data corruption and power fail recovery arises in SSDs and also HDDs when write data for write commands (or queued write commands when command queuing is supported) is cached in a volatile system memory and command completion issued prior to writing to media (flash or Hard Disc Drive). It is well known in the art that caching write data for write commands (or queued write commands when command queuing is supported) and issuing command completion prior to writing to media significantly improves performance.
As mentioned before in some prior art techniques, a battery-backed volatile memory is utilized to maintain the contents of volatile memory for an extended period of time until power is back and tables can be saved in flash memory.
Battery backup solutions for saving system management data or cached user data during unplanned shutdowns are long-established but have certain disadvantage including up-front costs, replacement costs, service calls, disposal costs, system space limitations, reliability and “green” content requirements.
What is needed is a system employing physically addressed SSD to reliably and efficiently preserve flash block management tables in the event of a power interruption.